home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group96b.txt / 000060_icon-group-sender _Tue Dec 3 12:04:32 1996.msg < prev    next >
Internet Message Format  |  1997-01-02  |  2KB
  1. Received: by cheltenham.cs.arizona.edu; Tue, 3 Dec 1996 12:27:39 MST
  2. Message-Id: <s2a41710.071@housmtp.oceaneering.com>
  3. X-Mailer: Novell GroupWise 4.1
  4. Date: Tue, 03 Dec 1996 12:04:32 -0600
  5. From: Charlie Hethcoat <CHETHCOA@oss.oceaneering.com>
  6. To: icon-group@cs.arizona.edu
  7. Subject: Icon vs. Java
  8. Mime-Version: 1.0
  9. Content-Type: text/plain
  10. Content-Disposition: inline
  11. Errors-To: icon-group-errors@cs.arizona.edu
  12.  
  13.  
  14.  
  15.     The question of using Icon in preference to Perl for CGI
  16. programming has come up periodically, and Icon, based on what I
  17. have seen, acquits itself well for that application.  Now Java has
  18. arrived.  The reason I write this is to provoke some feedback from the
  19. Icon community about whether Icon couldn't profitably be used for the
  20. same types of jobs as Java, maybe with some extensions to the runtime
  21. system.  Icon has always had a portable runtime interpreter, after
  22. all.
  23.  
  24. The portable runtime interpreter based on an abstraction of a
  25. computer is the classic software approach to object-code
  26. portability.  When the many eight-bit MPU chips appeared in the
  27. mid-70's, it seemed for a while that the UCSD Pascal system (based on
  28. the Pascal P interpreter of Niklaus Wirth) was the smart way to give
  29. everyone in the world the same programming language to play with.
  30. Eventually, of course, the 8086 CPU and the IBM PC came out, and the
  31. interpreter-based systems came to be considered as beneath contempt.
  32. Who needed portability?  Everyone had a PC and wanted speed.
  33. Portability was not too important, and such as it was, was at the
  34. source code level.
  35.  
  36. Now, with the Internet, interpreter systems are back in the
  37. name of portability of object code.  Suddenly the Intel CPU is
  38. not the only game in town, and code has to run--unchanged--on multiple
  39. CPU architectures all over the world.  Recompiling is not the answer;
  40. the Java runtime interpreter, which combines abstractions of both the
  41. computer and the network, is seen as the solution.
  42.  
  43. So my questions are:  what extensions would be required to give
  44. Icon the same characteristics as Java for the purpose of
  45. writing Web browser "applets"?  How easily could an Icon "plug-in" for
  46. Web browsers be to create?  Could a typical Web browser (e. g.
  47. Netscape) accept an Icon interpreter plug-in?  Is anyone considering
  48. doing this?  (I ask, of course, because I have not a clue about how to
  49. do it myself.)
  50.  
  51. Charlie Hethcoat
  52.